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REAL PARTY IN INTEREST 



The present application is assigned to INTERNATIONAL BUSINESS MACHINES 
CORPORATION, North Castle Drive, Armonk NY 10504, U.S.A. 

RELATED APPEALS AND INTERFERENCES 

No other appeals or interferences are known to Appellants, Appellants' legal 
representative, or assignee, which will directly affect, be directly affected by, or have a bearing 
on the Board's decision in the pending appeal. 

STATUS OF CLAIMS 

Claims 1-37 are pending in this application. All pending claims stand rejected and are 
now being appealed. 

STATUS OF AMENDMENTS 

No amendments were filed after final rejection. 
SUMMARY OF CLAIMED SUBJECT MATTER 

Claim 1 

The present invention is concerned with the internet (specification, page 1, lines 14-16). 
More specifically, the present invention addresses the problem of overloading of servers by 
requests received via the internet (specification, page 1, lines 14-22). 

Claim 1 is directed to a method for dynamically reconfiguring a proxy server network to 
deliver content by dynamically selling extra capacity. The term "proxy server" is defined at page 
3, lines 4-11 of the specification, and refers to a server that stores the same website information 
as an "originating" server and that may service a request for information in place of the 
"originating" server. An embodiment of the claimed method is illustrated in a flow chart shown 



2 



in FIGS. 4-8 of the present application and generally described at page 11, line 13 to page 18, 
line 4. Process steps particularly relevant to selling extra capacity in a proxy server are indicated 
as 100, 101, and 102 in FIG. 4, discussed at page 11, line 13 to page 12, line 21. A proxy server 
network is represented by elements 2, 3, 4 and 5 in FIG. 1, described at page 7, line 23 to page 8, 
line 5 and page 8, lines 9-16 of the specification. 

Claim 1 recites the step of determining unused capacity on the proxy server network for a 
period of time. (Blocks 100 and 101, FIG. 1; specification, page 11, line 16 to page 12, Hne 2) 
Claim 1 further recites the step of selling the unused capacity for a specified period of time to 
web sites or other service providers which need additional capacity. (Block 102, FIG. 1 ; 
specification, page 12, lines 3-21) 

As a final step, claim 1 recites using the unused capacity to serve requests to the web isites 
or other service providers which purchase the extra capacity for the period of time. (Block 204, 
FIG. 5 and block 400, FIG. 7; specification, page 15, lines 13-16) 

Claim 3 (dependent on claim L also argued separately) 

Claim 3 recites the additional step of providing a controller (e.g., reference numeral 10, 
FIG. 2 or reference numeral 3, FIG. 1) to monitor and control traffic fi:-om the web sites or other 
service providers to be within a limit of the capacity purchased. (Specification, page 9, line 21 to 
page 10, Hne 3; page 15, line 16 to page 16, line 3; page 17, lines 14-21) 

Claim 6 (indirectly dependent on claim L also argued separately) 

Claim 6 is dependent on claim 5, which is dependent on claim 4, which is dependent on 
claim 3, which was discussed just above. 

Claim 4 recites that the controller (e.g., reference numeral 3, FIG. 1) uses a domain name 
server based approach wherein the domain name server performs name to address mapping for 
assigning the request to proxy servers of the proxy server network (reference numeral 5, FIG. 1). 
(See specification, page 14, lines 11-14) 

Claim 5 recites that the domain name server based approach makes the domain name 
server of the proxy server network a primary domain name server, which is the only domain 
name server that can assign names to the proxy servers. (Block 201, FIG. 5; specification, page 
13, lines 10-13, page 13, line 22 to page 14, line 7) 
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Claim 6 recites that the domain name server based approach further includes the 
following steps: 

—the domain name server (reference numeral 7, FIG, 1) of the purchaser World Wide 
Web site routing the name to address map of the purchaser web site to the domain name server 
(reference numeral 3, FIG. 1) of the proxy network (Block 202, FIG. 5; specification, page 14, 
lines 8-17); 

"the primary domain name server mapping a fraction of the received mapping requests to 
servers in the proxy network based on an amount of unused capacity purchased (Block 400, FIG. 
7; specification, page 17, lines 14-18). 

Claim 13 (indirectly dependent on claim 1: argued with claim 6) 

The above discussion of claim 6 is applicable without significant change to claim 13. 

Claim 26 

Claim 26 is an independent claim directed to computer executable software code stored 
on a computer readable medium, where the code is for dynamically reconfiguring a proxy server 
network to deliver content by dynamically selling extra capacity. (Specification, page 4, lines 6- 
10; portions of the disclosure relevant to dynamically reconfiguring a proxy server network and 
dynamically selling extra capacity were set forth above in discussing claim 1) Claim 26 further 
recites that the code performs the same steps listed in claim 1 ; this honorable Board is 
respectfully referred to the above discussion of claim 1 in regard to the corresponding description 
in the disclosure of this application. 

Claim 28 (dependent on claim 26: also argued separatelv) 

Claim 28 recites code to perform the same step set forth in claim 3, which was discussed 
above; this honorable Board is respectfully referred to the above discussion of claim 3 in regard 
to the corresponding description in the disclosure of this application. 



Claim 31 (indirectly dependent on claim 26: also argued separately) 
Claim 31 is dependent on claim 30, which is dependent on claim 29, which is dependent 
on claim 28, which is discussed above. Claim 31 recites code to implement the same limitations 
described above with reference to claim 6; this honorable Board is respectfully referred to the 
above discussion of claim 6 in regard to the corresponding description in the disclosure of this 
application. 

Claim 32 

Claim 32 is an independent claim directed to a computer system for dynamically 
reconfiguring a proxy server network to deliver content by dynamically selling extra capacity. 
(Specification, page 4, lines 4-10; portions of the disclosure relevant to dynamically 
reconfiguring a proxy server network and dynamically selling extra capacity were set forth above 
in discussing claim 1) Claim 32 recites program code to control the system to perform the steps 
set forth in claim 1; this honorable Board is respectfully referred to the above discussion of claim 
1 in regard to the corresponding description in the disclosure of this application. 

Claim 34 (dependent on claim 32: also separately argued) 

Claim 34 recites code to implement the same function set forth in claim 3; this honorable 
Board is respectfully referred to the above discussion of claim 3 in regard to the corresponding 
description in the disclosure of this application. 

Claim 37 (indirectly dependent on claim 32: also separately argued) 
Claim 37 is dependent on claim 36, which is dependent on claim 35, which is dependent 
on claim 34, which is discussed above. Claim 37 recites code to implement the same limitations 
described above with reference to claim 6; this honorable Board is respectfully referred to the 
above discussion of claim 6 in regard to the corresponding description in the disclosure of this 
appUcation. 
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GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

(1) Claims 1-7, 9-15, 17, 19-21, 23, 24 and 26-37 are rejected under 35 U.S.C. § 102(e) 
as being anticipated by Oliver et al. (hereinafter "Oliver"), U.S. published patent application pub. 
no. US 2002/0133412. 

(2) Claims 8, 16, 18, 22 and 25 are rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Oliver, in view of "Official Notice". 

Appellants are of the view that the rejection under § 103 does not raise any issues apart 
from the failure of the Oliver reference to anticipate the claims rejected under § 102. 

ARGUMENT 

As will be explained, the rejections of the claims are improper because the Oliver 

reference simply fails to teach significant limitations of the claims argued below. In other words, 

the Oliver reference fails to satisfy the standard for anticipation, set forth as follows in Verdegaal 

Bros, V. Union Oil Co, of California, 814 F.2d 628, 631, 2 USPQ2d 1051,1053 (Fed. Cir. 1987): 

A claim is anticipated only if each and every element as set forth in the 
claim is found, either expressly or inherently described, in a single prior art 
reference, [quoted in MPEP § 2131] 

/. The Independent Claims are Not Anticipated by the Oliver Reference 

Although both Oliver and the present invention are concerned with aspects of the 
internet, the subject matter of the reference is not closely related to that of the present 
application. As noted above, the present invention is directed to solving the problem of 
overloading of servers with requests received via the internet. (Specification, page 1, lines 14- 
22) In addition, the present invention allows proprietors of server networks to benefit 
commercially by selling excess capacity in the server networks. (Specification, page 3, lines 17- 
22; page 4, lines 17-22) The present invention realizes these goals by determining unused 
capacity in a proxy server network for a period of time, selling the unused capacity for a 
specified period of time to web sites or other service providers which need additional capacity, 
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and using the unused capacity to serve requests to the web sites or other service providers that 
purchase the extra capacity. (See, e.g., claim 1) 

The Oliver reference is not concerned with transfers of unused capacity from a server 
network to a web site that needs additional capacity. Rather, Oliver addresses the problem of 
how to charge internet users for access to content provided via the internet. (Page 2, ^[[0028]) 
Oliver's basic approach to solving this problem is for each user to have a "home" service 
provider which issues an authentication token to the user for each online session. (FIG. 1 ; page 
6, Tf[0126]) Content providers receive payment via the home service provider for charges 
incurred by the user for accessing content controlled by the content providers. (Page 17, claim 1, 
paragraphs (b) - (d)) 

Oliver fails to teach or disclose any one of the three listed method steps of claim 1 : 

-determining unused capacity in a proxy server network; 

-selling the unused capacity to web sites or other service providers which need 
additional capacity; and 

-using the unused capacity to serve requests to the web sites or other service providers 
that purchased the capacity. 

To put the matter concisely, Oliver teaches a system for charging end-users for access to 
content via the Web, and has nothing to do with selling excess server capacity to web sites. 

Having stated their contentions in general terms, appellants will now debunk the 
Examiner's reliance on certain portions of the Oliver reference as allegedly disclosing claim 
elements. 

In regard to the claimed step of determining unused capacity in a proxy server network, 
the Examiner has relied on portions of Tf[0077] (page 4) and T|[0100] (page 5) of the reference. 
(See page 2, paragraph 6 of the Final Office Action.) But neither of these passages discloses 
determining unused capacity in a proxy server network. 

Tf[0077] states general goals of Oliver's system as including provision of a "free 
marketplace for digital information" and controlling access to system resources. It is clear from 
the context of the reference that the resources to be controlled are information or content 
resources. Nothing in the reference indicates that the resources to be controlled are computing 
capacity on a server network. 
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^[0100] generally describes the desirability of providing various classes of service to fit 
price requirements or usage demands. Again it is clear from the context of the reference that the 
service classes are for end users. Again the passage has nothing to do with determining unused 
capacity in a proxy server network. 

In attempting to defend his position in regard to this limitation (bottom of page 7 to top of 
page 8 of the Final Office Action), the Examiner also throws in a reference to 1f1f[0036] and 
[0037] of Oliver as supposedly defining the term "resources" which appears in ^[0077]. The 
Examiner further asserts that the term "resources" should be taken to mean "capacity", even 
though the reference does not so state. 

Again the Examiner mistakes the meaning of the reference. ^[0036] clearly is concerned 
with "sale of information or software" (to quote directly) and not with computer capacity. 
Moreover, even if the passages cited by the Examiner were related to computer capacity, none 
comes close to teaching the step of determining excess capacitv in a proxy server network. It 
appears that the Examiner has completely misunderstood the reference, while also failing to 
address the actual claim language presented for his consideration. 

In regard to the two claimed steps of selling the unused capacity and using it to serve 
requests of the purchasing web site, the Examiner relies on a portion of Tf[0120] (page 6) of 
Oliver. But this passage too has no relation to the claim language against which it is cited. 
^[0120] generally describes the concept of a "session" and refers to an authentication token 
provided to the user for the session. There is nothing whatsoever in the passage to teach or 
suggest selling excess server capacity. Neither does the passage refer in any way to a web site or 
other service provider which needs additional capacity. 

The Examiner further explained his position regarding these claim elements at the top of 
page 8 of the Final Office Action, but in doing so the Examiner mischaracterized the teachings of 
the reference. 

The Examiner stated that "Oliver teaches the system of selling services/capacity and 
charging clients for such services". Here the Examiner paints with much too broad a brush. A 
much more accurate characterization of Oliver's teaching is that the reference teaches selling 
information and other content to end users. The main issue in Oliver is how to collect micro- 
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charges for end user access to content. (See ^[0003] of the reference.) The reference is not 
generally concerned, as the Examiner suggests it is, with charging for "services/capacity". 

To summarize the appellants' contentions in regard to the independent claims, the cited 
reference fails to teach or suggest not just one, but virtually all of the claimed step limitations, 
and so clearly fails to anticipate the independent claims. Reversal of the rejections under § 102 
is therefore respectfully requested. 

The foregoing arguments are equally applicable to all three independent claims 1 , 26 and 
32, and thus support allowability of all of the pending claims. 

//. Separate Argument in Support of Claims 3-8, 28-31^ and 34-37 

Claim 3 adds to the method of claim 1 the step of providing a controller to monitor and 
control traffic fi*om the web sites or other service providers to be within a limit of the capacity 
purchased. Inasmuch as the Oliver reference has nothing to do with purchasing capacity to 
service traffic from another web site, this limitation also is not taught by the reference. 
Accordingly, claim 3 is allowable on grounds that are independent of the grounds argued above 
in regard to claim 1 and the other independent claims. 

At paragraph 8 on page 3 of the Final Office Action, the Examiner cites ^{[01 13] (page 5) 
and ^[0332] (page 14) of the Oliver reference as allegedly disclosing this limitation. However, 
once again the passages cited by the Examiner do not support his reliance thereon. 

Tf[01 13] discusses providing a network of servers that cooperate to provide a single point 
of contact for an end user. This passage says nothing about limiting traffic fi'om another web site 
and does not mention an amount of capacity that has been purchased. Thus this passage fails to 
disclose the limitation of claim 3. 

T|[0332] discloses determining whether an end user has sufficient credits to view a 
resource. This is done by comparing the amount of credit available to the user with the value 
charged for the resource that the user wishes to access. Once again, there is no discussion of 
limiting traffic fi*om another website or of an amount of capacity that has been purchased. This 
passage as well fails to disclose the limitation of claim 3. 
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At paragraph 45 on page 8 of the Final Office Action, in attempting to respond to 
appellants' arguments, the Examiner makes explicit his misinterpretation of the reference. The 
Examiner asserts that "credit(x). . .is the amount of resources/capacity purchased by the end 
user". But neither Tl[0332] nor the balance of the reference supports this interpretation. 
"Credit(x)" is merely the amount of value to the user's credit, and does not represent any 
particular amount of "capacity" purchased by the user. The end users in Oliver are not interested 
in server capacity but only in access to content, software, and the like. 

The Examiner further states at this point that "if credit(x) falls below a certain threshold, 
[the] server stops servicing its services/capacity". This too is an error on the Examiner's part. 
The passage says nothing about any threshold. Rather, what is going on is that if the user doesn't 
have enough credit to pay for a resource, he/she is denied access to the resource. There is no 
discussion in the reference of limiting traffic from a web site to an amount of capacity previously 
purchased. 

For these reasons, appellants respectfully submit that claim 3 would be allowable even if 
claim 1 were not. This separate argument is also applicable to claims 28 and 34 which are to 
essentially the same effect as claim 3, and also to claims 4-8 which depend from claim 3, claims 
29-31 which depend from claim 28, and to claims 35-37 which depend from claim 34. 

///. Separate Argument in Support o f Claims 6-8, 13-16, 31 and 37 

In particularly pertinent part, claim 6 recites that the domain name server of the purchaser 
World Wide Web site routes the name to address map of the purchaser World Wide Web site to 
the domain name server of the proxy network. This claim limitation also is not disclosed by the 
Oliver reference. 

At paragraph 11, page 3 of the Final Office Action the Examiner asserts that teaching in 
regard to this limitation is found at 1f[01 13] (page 5) and Tnf[0249]-[0260] of the Oliver reference. 
Yet again, the Examiner has cited passages of the reference that fail to provide support for his 
position. 

^[0113], as discussed above, relates to providing a network of servers that cooperate to 
provide a single point of contact for an end user. There is no discussion in this passage 
concerning name to address maps, nor of routing such maps from one server to another. 
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^^[0249]-[0260] simply list data stored with respect to a current session. This data does 
not constitute a name to address map and, in any case, is not routed from one server to another. 

At paragraph 46, page 8 of the Final Office Action, the Examiner throws into the mix 
^^[0023], [0031] and [0032] (page 2) of the reference, even though these passages also fail to 
provide support for his position. First of all, the Examiner mischaracterizes these passages by 
asserting that "domain name service is explicitly mentioned" therein. In fact, while the word 
"domain" appears in some of these paragraphs, neither "domain name" nor "domain name 
service" is mentioned anywhere in these paragraphs. More important, not one of these 
paragraphs is in the slightest way concerned with name to address maps, nor routing such maps 
from one server to another. Briefly, 1f[0023] refers to "public domain" (i.e., non-proprietary) 
server software; Tf[0031] is concerned with providing access control based on individual user ID 
rather than on domain ID, and f [0032] is concerned with providing demographic analysis of user 
traffic. At best the Examiner is grasping at straws by trying to rely on these paragraphs. It is 
also notable that in his purported response at the next to last paragraph on page 8 of the Final 
Office Action, the Examiner does not even refer to the claim limitation of routing the name to 
address map to the domain name server of the proxy network. 

For these reasons, appellants respectfully submit that claim 6 would be allowable even if 
claims 1 and 3 were not. This separate argument is also applicable to claims 13, 31 and 37 
which are to essentially the same effect as claim 3, and also to claims 7 and 8 which depend from 
claim 3 and to claims 14-16 which depend from claim 13. 

IK Rejections under §103 

As noted above, the rejections under § 103 are not believed to raise any pertinent issues 
that have not been fiiUy discussed above. Accordingly, the claims rejected under § 103 will not 
be further argued, except as noted above. 
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CONCLUSION 



The rejections of claims 1-37 are improper at least because the reference relied upon by 
the Examiner fails to teach or suggest at least some element of every claim. Therefore, 
Appellants respectfully request that the Examiner's rejections be reversed. 

As required by 37 CFR §4 1.3 7(a)(1), this Brief is filed within two months from the date 
of mailing of Appellants' Notice of Appeal (Le,, within two months of September 1, 2004); as 
such, no extension of time is believed due. However, if any additional fees are due in 
conjunction with this matter, the Commissioner is hereby authorized to charge them to Deposit 
Accoxmt 50-0510 . An Appendix of claims involved in this appeal is attached hereto. 

If any issues remain, or if the Examiner or the Board has any further suggestions for 
expediting allowance of the present application, kindly contact the undersigned using the 
information provided below. 



Respectfully submitted, 




October 6, 2004 
Date 



Nathaniel Levin 

Registration No. 34,860 

Buckley, Maschoff & Talwalkar llc 

Five Elm Street 

New Canaan, CT 06840 

(203) 972-3460 



Attachment: Appendix of claims 
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APPENDIX 



1 . A method for dynamically reconfiguring a proxy server network to deliver content by 
dynamically selling extra capacity, comprising the steps of: 

determining unused capacity on the proxy server network for a period of time; 

selling the said unused capacity for a specified period of time to web sites or other service 
providers which need additional capacity; 

using said unused capacity to serve requests to the said web sites or other service 
providers purchasing the extra capacity for said period of time. 

2. The method of claim 1, wherein the selling method of the unused capacity can be through 
market-based mechanisms. 

3. The method of claim 1, comprising the additional step of providing a controller to 
monitor and control traffic fi*om the web sites or other service providers to be within a limit of 
the capacity purchased. 

4. The method of claim 3, wherein said controller uses a domain name server based 
approach wherein the domain name server performs name to address mapping for assigning the 
request to proxy servers of the proxy server network. 

5. The method of claim 4, wherein the said domain name server based approach makes the 
domain name server of the proxy server network a primary domain name server, which is the 
only domain name server that can assign names to the proxy servers. 

6. The method of claim 5, wherein said domain name server based approach further 
comprises the steps of: 
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the domain name server of the purchaser World Wide Web site routing the name to 
address map of said purchaser World Wide Web site to said domain name server of the proxy 
network; and 

said primary domain name server mapping a fraction of the received mapping requests to 
servers in the proxy network based on an amount of unused capacity purchased. 

7. The method of claim 6, wherein mapping requests which were not mapped to servers in 
the proxy network are returned by said primary domain name server to said domain name server 
of the purchaser World Wide Web site to be mapped to a server of the purchaser's World Wide 
Web site. 

8. The method of claim 6, wherein mapping requests which were not mapped to servers in 
the proxy network are assigned by said primary domain name server to servers in the purchaser 
World Wide Web site using an assignment algorithm provided by said domain name server of 
the purchaser World Wide Web site. 

9. The method of claim 1, wherein said unused capacity can be based on an estimate of the 
usage of the proxy server network over time and said unused capacity can be provided based on 
the best efforts of the proxy server network. 

10. The method of claim 9, comprising an additional step of providing a controller to monitor 
and control the traffic from the purchaser to the proxy server network. 

1 1 . The method of claim 1 0, wherein said controller uses a domain name server based 
approach wherein the domain name server performs name to address mapping for assigning the 
request to proxy servers of the proxy server network. 
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12. The method of claim 11, wherein the said domain name server based approach makes the 
domain name server of the proxy server network a primary domain name server, such that no 
other domain name server can assign names to the proxy servers. 

13. The method of claim 12, wherein said domain name server based approach comprises the 
steps of: 

the domain name server of the purchaser World Wide Web site routing the name to 
address map of said purchaser World Wide Web site to said domain name server of the proxy 
network; and 

said domain name server of the proxy network mapping a fraction of received mapping 
requests to servers in the proxy network based on an amount of unused capacity on the proxy 
server available. 

14. The method of claim 13, wherein said domain server of the proxy network monitors a 
load level on the proxy servers to adjust said fraction based on said unused capacity on the proxy 
server at any given time. 

15. The method of claim 14, wherein mapping requests which were not mapped to servers in 
the proxy network are returned to said domain name server of the purchaser World Wide Web 
site to be mapped to a server of the purchaser's World Wide Web site. 

16. The method of claim 14, wherein mapping requests which were not mapped to servers in 
the proxy network are assigned to servers in the purchaser World Wide Web site using an 
assignment algorithm provided by said domain name server of the purchaser World Wide Web 
site. 

17. The method of claim 9, wherein a financial charge for the unused capacity will be based 
on the purchaser World Wide Web site's actual usage of the unused capacity. 
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18. The method of claim 2, wherein said selling method consists of selling the unused proxy 
capacity through an auction. 

19. The method of claim 2, wherein the selling method consists of selling the unused proxy 
capacity through a real-time continuous market. 

20. The method of claim 5, wherein said controller sets the fraction of requests to be served 
by the proxy network, comprising the steps of: 

setting an initial value based on a number provided by the purchaser World Wide Web 
site on the fraction of total requests needed to be routed to the proxy servers; 

monitoring an actual number of World Wide Web object requests served by the proxy 
servers; 

adjusting the fraction of World Wide Web object requests served so that the actual 
number of World Wide Web object requests served does not use more proxy server capacity than 
was purchased. 

21 . The method of claim 20, wherein the remaining object requests which were not served by 
the proxy server are returned to said domain name server of the purchaser World Wide Web site 
to be served by a server of the purchaser's World Wide Web site. 

22. The method of claim 20, wherein the remaining object requests which were not served by 
the proxy server are assigned to servers in the purchaser World Wide Web site using an 
assignment algorithm provided by said domain name server of the purchaser World Wide Web 
site. 

23. The method of claim 5, wherein said controller sets the fraction of requests to be served 
by the proxy network, comprising the steps of: 

setting an initial value based on an estimate from the purchaser World Wide Web site on 
the fraction of total requests needed to be routed to the proxy servers; 
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monitoring the actual number of World Wide Web object requests served by the proxy 
servers; 

adjusting the fraction of World Wide Web object requests served so that the actual 
number of World Wide Web object requests served does not use more proxy server capacity than 
was purchased. 

24. The method of claim 23, wherein object requests which were not served by the proxy 
server are returned to said domain name server of the purchaser World Wide Web site to be 
served by a server of the purchaser's World Wide Web site. 

25. The method of claim 23, wherein object requests which were not served by the proxy 
server are assigned to servers in the purchaser World Wide Web site using an assignment 
algorithm provided by said domain name server of the purchaser World Wide Web site. 

26. Computer executable software code stored on a computer readable medium, the code for 
dynamically reconfiguring a proxy server network to deliver content by dynamically selling extra 
capacity, comprising: 

code to determine unused capacity on the proxy server network for a period of time; 

code to sell the said unused capacity for a specified period of time to web sites or other 
service providers which need additional capacity; 

code to use said unused capacity to serve requests to the said web sites or other service 
providers purchasing the extra capacity for said period of time. 

27. The computer executable code of claim 26 further comprising code to sell the unused 
capacity through market-based mechanisms. 

28. The computer executable code of claim 27 further comprising code to monitor and 
control traffic from the web sites or other service providers to be within a limit of the capacity 
purchased. 
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29. The computer executable code of claim 28 further comprising code to use a domain name 
server based approach wherein the domain name server performs name to address mapping for 
assigning the request to proxy servers of the proxy server netv^ork. 

30. The computer executable code of claim 29 further comprising code to make the domain 
name server of the proxy server network a primary domain name server, such that no other 
domain name server can assign names to the proxy servers. 

3 1 . The computer executable code of claim 30 further comprising: 

code to make the domain name server of the purchaser World Wide Web site route the 
name to address map of said purchaser World Wide Web site to said domain name server of the 
proxy network; and 

code to make the primary domain name server map a fraction of the received mapping 
requests to servers in the proxy network based on the amount of unused capacity purchased. 

32. A computer system for dynamically reconfiguring a proxy server network to deliver 
content by dynamically selling extra capacity, comprising: 

a memory having at least one region for storing computer executable program code; and 
a processor for executing the program code stored in memory, wherein the program code 
includes: 

code to determine unused capacity on the proxy server network for a period of time; 

code to sell the said unused capacity for a specified period of time to web sites or other 
service providers which need additional capacity; 

code to use said unused capacity to serve requests to the said web sites or other service 
providers purchasing the extra capacity for said period of time. 

33. The computer system of claim 32 further comprising code stored in memory to sell the 
unused capacity through market-based mechanisms. 
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34. The computer system of claim 33 further comprising code stored in memory to monitor 
and control traffic from the web sites or other service providers to be within a limit of the 
capacity purchased. 

35. The computer system of claim 34 further comprising code stored in memory to use a 
domain name server based approach wherein the domain name server performs the name to 
address mapping for assigning the request to proxy servers of the proxy server network. 

36. The computer system of claim 35 further comprising code stored in memory to make the 
domain name server of the proxy server network a primary domain name server, which is the 
only domain name server that can assign names to the proxy servers. 

37. The computer system of claim 36 further comprising: 

code stored in memory to make the domain name server of the purchaser World Wide 
Web site route the name to address map of said purchaser World Wide Web site to said domain 
name server of the proxy network; and 

code stored in memory to make the primary domain name server map a fraction of the 
received mapping requests to servers in the proxy network based on the amount of unused 
capacity purchased. 
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